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1 FIELD OF THE INVENTION 

2 

3 The present invention relates generally to virtual desktops and project-time 

4 tracking and, for example, to computer program products, methods, and computer 

5 systems for providing virtual desktops and for project-time tracking. 
6 

7 BACKGROUND OF THE INVENTION 
8 

9 Systems and methods for project-time recording are known which enable a user 



10 to determine and record the amounts of time spent by a person on a plurality of prof 

1 1 acts. These prior art systems require Interaction tools which enable the user to iden- 

12 tify beginnings and endings of project or work-related time periods, as well as project 

13 identification data. For example, the documents DE 44 43 850 A1 and DE 195 16 

14 975 A1 disclose systems for recording project-related information including a port- 

15 able device with a keyboard, which enables the user to enter project-related data and 

16 to indicate the beginnings and endings of project-related or work-related time peri- 

17 ods. The information entered by the user is stored in the portable device for later 

18 transmission to a computer system in which the collected data are analyzed. Similar 

1 9 known time recording systems are directly implemented on computer systems without 

20 making use of portable devices. 

21 In the current personal-computer technology, graphical user interfaces (GUIs) 

22 are used to facilitate the interaction between a user and a computer. Prevailing oper- 

23 ating systems, such as Microsoft Windows <S>, Unix <S>> Linux <B> and MacOS <e>, have 

24 graphical user interfaces which provide a virtual desktop (sometimes simply called 

25 "desktop") to the user. The user can place virtual objects, e.g. windows, link icons and 

26 tool bars, on this desktop. Open tasks (or applications) may be displayed by applica- 

27 tion windows, or, in a "minimized" form, by application icons which may appear in a 

28 "task bar" on the desktop. Some of the known operating systems, (such as Unix/Linux 

29 with GUIs, such as KDE, GNOME, CDE) are able to handle a plurality of desktops at 

30 the same time and enable the user to select one of the virtual desktops to be dis- 

31 played on the screen. Microsoft Windows NT offers multi-desktop capabilities as an 

32 optional feature called MultiDesk within the "Windows NT Resource Kit". The user is 
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1 able to activate different tasks on different desktops thereby enlarging the effective 

2 screen space for displaying the application windows. It is also possible to group le- 

3 lated tasks into different desktops, as described in U.S. patent No. 5,564,002. 
4 

5 SUMMARY OF THE INVENTION . 

6 

7 The invention is directed to a computer program product including program 

8 code, when executed on a computer, for tracking the time spent by a user working 

9 with the computer for different projects. The program code is arranged to provide a 

10 plurality of virtual desktops which are assignable to different projects and switchable 

11 by the user, and to track the time spent by the user working on the different desktops, 

12 thereby tracking the time spent on the projects to which the respective desktops are 

13 assigned. 

14 According to another aspect, a computer program product is provided for ex- 

15 tending a computer's operating system which provides a virtual desktop. The com- 

16 puter program product includes program code, when executed, for tracking the time 

17 spent by the user working with the computer for different projects. The program code 

18 is arranged to extend the operating system's desktop functionality to a multi-desktop 

19 functionality, wherein the desktops are switchable by the user and are assignable to 

20 different projects; and to track the time spent by the user working on the different 

21 desktops, thereby tracking the time spent on the projects to which the respective 

22 desktops are assigned. 

23 According to another aspect, a computer program product is provided for ex- 
t 24 tending a computer's operating system which provides a plurality of virtual desktops 

25 switchable by a user. The computer program product includes program code, when 

26 executed, for tracking the time spent by the user working with the computer for differ- 

27 ent projects, wherein desktops are assigned to projects. The program code is sr- 

28 ranged to track the time spent by the user working on the different desktops, thereby 

29 tracking the time spent on the projects to which the respective desktops are as- 

30 signed. 

31 According to another aspect, a computer is provided arranged to track the time 

32 spent by a user working with the computer for different projects. The computer com- 
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1 prises a desktop manager arranged to provide a plurality of virtual desktops which 

2 are assignable to different projects and switchable by the user; and a project time 

3 tracker arranged to individually track the time spent by the user working on the differ- 

4 ent desktops, thereby tracking the time spent on the projects to which the respective 

5 desktops are assigned. 

6 According to another aspect, a method is provided of tracking the time spent by 

7 a user working with a computer for different projects. The computer is arranged to 

8 provide a plurality of virtual desktops assigned to different projects. The method 

9 comprises the user working on a desktop which is assigned to a currently handled 

10 project and switching to another of the desktops when another project is handled; and 

11 the computer tracking the time spent by the user working on the different desktops, 

12 thereby tracking the time spent on the projects to which the respective desktops are 

13 assigned. 

14 According to another aspect, a computer program product is provided including 

15 program code, when executed on a computer, for providing a graphical user interface 

16 with a plurality of virtual desktops presenting link icons to a user. The program code is 

17 arranged to provide the plurality of virtual desktops in a way that the user can switch 

18 from one to another as desired, and to enable the user to define, as individual desk- 

19 top settings, the link icons individually for the virtual desktops, so that upon switching 

20 from one of the desktops to another, different link icons are displayable. 

21 According to another aspect, a computer is provided having a graphical user 

22 interface with a plurality of virtual desktops. The computer comprises a desktop man- 

23 ager arranged to provide the plurality of virtual desktops switchable by the user. The 

24 virtual desktops present link icons. The desktop manager is arranged to enable the 

25 user to define the link icons individually for the virtual desktops, so that, upon switch- 

26 ing from one of the desktops to another, different link icons are displayable. 

27 According to another aspect, a method provides a computer user with a plurality 

28 of virtual desktops presenting link icons to the user. The virtual desktops are 

29 switchable by the user. TTie method comprises enabling the user to define the link 

30 icons individually for the virtual desktops, and, when a switch is made from one 

31 desktop to another, displaying different link icons for the different desktops, accord- 

32 ing to the desktop-individual link-icon definition. 
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1 Other features are inherent in the products and methods disclosed or will be- 

2 come apparent to those skilled in the art from the following detailed description of 

3 embodiments and its accompanying drawings. 

4 

5 DESCRIPTION OF THE DRAWINGS 
6 

7 Embodiments of the invention will now be described, by way of example, and 

8 with reference to the accompanying drawings, in which: 

9 Fig. 1 illustrates a GUI with an exemplary virtual desktop; 

10 Fig. 2 illustrates a switch from one virtual desktop to another; 

1 1 Fig. 3 is a flow diagram of an embodiment in which project-time lecording 

12 is started and stopped by switching from one desktop to another; 

13 Fig. 4 is a flow diagram similar to Fig. 3 of another embodiment in which 

14 the project-time recording can be started and stopped independently of a desktop 

15 switch; 

16 Fig. 5 illustrates an embodiment of project-time tracking based on event 

17 logging; 

18 Fig. 6 illustrates another embodiment of project-time tracking based on 

19 cumulating project-times; 

20 Fig. 7 shows an exemplary interface of a configurator; 

21 Fig. 8 shows a diagrammatic representation of layers of a computer r>- 

22 eluding software for virtual-desktop management and project-time tracking; 

23 Fig. 9 is a high-level architecture diagram of a virtuaWesktop-and-project- 

24 time-tracking system; 

25 Fig. 10 is an architecture diagram similar to Fig. 9 illustrating an crnbodi- 

26 ment in which the virtual-desktop-and-project-time-tracking system is an extension to 

27 a Microsoft Windows operating system; 

28 Fig. 11 is an architecture diagram similar to Fig. 9 illustrating another embodi- 

29 ment in which the virtual-desktop and project-time-tracking system is an extension to 

30 a Unix operating system. 
31 
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1 DESCRIPTION OF THE PREFERRED EMBODIMENTS 

2 

3 Fig. 1 illustrates a GUI with an exemplary virtual desktop. Before proceeding 

4 further with the description of Fig. 1 , however, a few Herns of the embodiments will be 

5 discussed. 

6 In some of the embodiments the time spent by a user working with a computer 

7 for different projects is tracked, in these embodiments, a plurality of virtual desktops 

8 Is provided which are assignable to different projects and switchable by the user. By 

9 tracking the time spent by the user worthing on the different desktops, a record can be 

10 created of the time spent on each of the projects to which the individual desktops are 

1 1 assigned. The term "project" is herein used as a very general term referring to related 

12 items of work, not limited to the term's meaning in the classic business jargon. For 

13 example, besides its classical meaning, it may include different job functions of a 

14 user, jobs related to different departments or work groups in the user's company, jobs 

15 for different clients, etc. In the general meaning used here, a project may, of course, 

16 combine work for several "projects" in the classical meaning, or work for one 

17 "project" in the classical meaning may be separated into several projects. 

18 The computer has a graphical user interface (GUI) with a plurality of virtual 

19 desktops switchable by the user. The virtual desktops, including the desktop- 

20 switching functionality, are controlled by a desktop manager. The switching from one 

21 desktop to another forms a "switch event". The virtual desktops present link icons. In 

22 some of the embodiments the desktop manager enables the user to define the link 

23 icons individually for the virtual desktops, so that, upon switching from one of the 

24 desktops to another, different link icons are displayable. Some of these embodi- 

25 ments with individually definable link icons are equipped with the above-mentioned 

26 project-time-tracking functionality associated with the different desktops, others have 

27 no project-time-tracking functionality. Similarly, some of the embodiments with prof 

28 ect-time-tracking functionality have no individually definable link icons (i.e. the link 

29 icons are the same in all the desktops). 

30 The GUI enables the computer user to interact with the computer. The graphical 

31 interface presented to the user is the "virtual desktop", in analogy to an (actual) 

32 desktop on which work is carried out Elements displayed on a virtual desktop include 
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1 link icons, control panels, pop-up and pull-down menus, a pointing-device-controlled 

2 cursor (e.g. a mouse or track-ball cursor), task bars, and application windows. These 

3 desktop elements can be individually placed on a desktop background. Generally, the 

4 user is able to define and change their position, appearance and status, as well as 

5 the appearance of the desktop background. Link icons represent links to, for exam- 

6 pie, programs, data files, hardware devices, file folders, Internet resources (URLs, 

7 Web-pages). Clicking on a link icon with the pointing device enables the user to 

8 quickly access the linked resource, e.g. starting the represented program or opening 

9 the represented data file. Control panels and menus, for example, enable the user to 

10 control or configure system resources or programs. Application windows represent 

11 an interface between running applications (tasks) and the user. A task bar indicates 

12 the presently running programs (tasks), for example by means of task icons. Applica- 

13 tion windows can be "minimized", a task with a minimized application window, for 

14 example, is only indicated by its task icon in the task bar. Of course, the above enu- 

15 meration of desktop elements is not complete; rather, there may be further desktop 

16 elements enabling the user to interact with different resources in various manners. A 

17 data representation of the particular desktop configuration chosen by the user (i.e. a 

18 definition of the different desktop elements displayed and their appearance and po- 

19 sition, a desktop background eta) is permanently stored in the computer so that the 

20 configuration is maintained when the user logs out, and is restored at the next log-in. 

21 In multi-user systems, each user can have a personal configuration, and all user- 

22 individual desktop configurations are stored. When a user logs in, his or her personal 

23 configuration is restored. 

24 As mentioned above, in some of the embodiments, the virtual desktops are 

25 provided by a piece of software called "desktop manager". A desktop manager is, in 

26 some of the embodiments, a part of a computer's operating system kernel, i.e. is rurv 

27 ning in kernel mode (such as the GUI in Microsoft Windows NT 2000), in other em- 

28 bodiments it is a "standard utility program" running in user mode (such as the GUIs in 

29 Linux). In order to display the desktop elements (link icons, mouse cursor, application 

30 windows, task bar etc.) and to bestow the required functionality on them, the desktop 

31 manager interacts with other parts or components of the operating system. For ex- 

32 ample, it interacts with a windov^managem nt system responsible for the display, 
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1 management and control of application windows. In some embodiments the desktop 

2 manager is a software component separated from other software components, in 

3 other embodiments it is combined with other software Items, such as the window- 

4 - management system. The term "desktop manager" is hence a functional term, which 

5 does not necessarily imply that a separate software component, solely devoted to 

6 desktop management, is provided. 

7 In the embodiments, not only one, but several virtual desktops are available to 

8 the user. Typically, only one of these desktops is displayed (hereinafter the "active 

9 desktop"), whereas the other desktops are either not displayed, or are only displayed 

10 in a space-saving representation, e.g. in the form of a desktop symbol within a desk- 

11 top-symbol bar. When required, the user can switch from the currently active desktop 

12 to another desktop, thereby making this other desktop visible and disposing of the 

13 previously active desktop. The time during which a certain desktop is active (e.g. the 

14 time between two switches) is also referred to in this patent as a "desktop session". 

15 The desktop manager is able to handle a plurality of different virtual desktops. In 

16 some of the embodiments, switching between desktops may be performed by the 

17 user actuating predefined keys or key combinations ("short cuts"), e.g. [Ctrl] + [F1] 

18 (wherein "F1" may indicate that a desktop No. 1 is selected) and/or by clicking on the 

19 desktop symbol representing the desktop desired. In some of the embodiments, the 

20 switching functionality, including the display of the desktop symbols, is assisted by an 

21 element of software called a "pager, which is a part of the desktop manager 

22 (although in some of the embodiments with modular software design, a pager may be 

23 a separable software component). 

24 As mentioned at the outset, in the prior art plural desktops are used to enlarge 

25 the effective screen space for displaying the application windows of the currently ao- 

26 tive tasks. In such known multi-desktop systems, the users typically group functionally 

27 related tasks in the different desktops, for example Web-browser application win- 

28 dows are located in a first desktop, e-mail related application windows in a second 

29 one, word-processor-related application windows in a third one, and system- 

30 monitoring application windows in a fourth one, etc. 

31 In the embodiments with project-time-tracking functionality, the plural desktops 

32 do not only serve to enlarge the effective stream space, but they are also associated 
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1 with different projects the user works for. Thereby, by working on a particular desktop, 

2 the user Indicates that he or she is currently working for a particular project, i.e. the 

3 project with which the active desktop is associated. Typically, the user is aware of the 

4 meaning of the different projects, but from the computer's "view" a project is a 

5 (meaningless) entity, e.g. identified by a project identifier (or descriptor) which en- 

6 ables it to be distinguished from other projects. For example, a software engineer 

7 responsible for developing a new program and maintaining an old program might 

8 define two projects, project No. 1 being the project "development", and project No. 2 

9 the project "maintenance". He or she might associate desktop No. 1 with project No. 

10 1 and desktop No. 2 with project No. 2, and choose desktop No. 1 when s/he works 

11 on project No. 1, and desktop No. 2 when s/he works on project No. 2. The computer 

12 is arranged to individually track the times spent by the user working on the different 

13 desktops. Due to the association between desktops and projects, the times spent on 

14 the different projects are thereby ind i vidually tracked. 

15 There may be a one-to-one (1:1) relationship between desktops and projects 

16 which means that one desktop is associated with each of the projects. Alternatively, 

17 there may be a many-to-one (N:1) relationship between desktops and projects, which 

18 means that more than one desktop may be associated with a project For example, if 

19 a project can be subdivided into sub-projects, one desktop may be associated with 

20 each of the sub-projects. Hence, in N:1 relationships, the time spent with a certain 

21 desktop, the "desktop time", need not necessarily be the "project-time** of the project 

22 the desktop is associated with, since other desktops may also contribute to the proj- 

23 ect time. Therefore, a distinction is sometimes made in this patent between desktop 

24 time and project time, for example in the detailed description of embodiments with an 

25 N:1 relationship between desktops and projects. On the other hand, in more general 

26 contexts in this patent, the term "project-time" is also used with a more generic 

27 meaning also covering "desktop time". 

28 In the embodiments, the recording of the time spent by the user working on the 

29 different projects is based on "start" and "stop" events indicative of a commencement 

30 or cessation of work. In the simplest mann r of project-tim recording, the start event 

31 is the switch to the desktop assigned to the respective project from another desktop, 

32 or the start of the computer (or the user log-in). The stop event may be defined in the 
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1 same way by the switch from the current desktop to another desktop, or by the shut- 

2 down of the computer (or the user log-out). The recorded project times are then sinv 

3 ply the time intervals during which the different project-assigned desktops have been 

4 active. However, depending on the kind of project-work, such a definition of the start 

5 and stop events might result in an insufficiently accurate time measurement For ex- 

6 ample, if a user leaves his or her work place, but leaves the computer running, the 

7 time of his or her absence is counted as time spent on the project to which the cur- 

8 rently active desktop is assigned. Therefore, in other embodiments a start event is 

9 defined by the user manually operating a control element indicative of a start of work, 

10 or by the user exhibiting user activity on the computer for the first time after the switch 

11 or a stop (e.g. by pressing any key on the keyboard, moving the cursor, making a 

12 voice input, etc.). Likewise, a stop event can be defined by the user manually operat- 

13 ing a control element indicative of a stop of work, or by a failure to exhibit any user 

14 activity on the computer for a specified inactivity time (which may, for example, be a 

15 predetermined time ranging from some minutes to one hour f depending on the kind 

16 of work). In other embodiments, the user is required to regularly confirm that s/he is 

17 still working, e.g. by regularly pressing a "dead-man's button" (which may be repre- 

18 sented on the computer by a certain key or combination of keys or a clickable graphi- 

19 cal button). Not operating the dead-man's button for more than an accepted dead 

20 time (e.g. one minute) is a stop event Since stop events may occur during a desktop 

21 session (or the time recording may not be started when a switch to the desktop is 

22 performed), the "desktop time'' may of course, be shorter than the "desktop session 

23 time" (i.e. the time during which the desktop was active). 

24 There are different ways to actually determine the total time spent on the differ- 

25 ent projects between the start and stop events. In some of the embodiments, the start 

26 and stop events are logged (e.g. the nature of an event and its time of occurrence are 

27 recorded) for each project-assigned desktop. To obtain project-time statistics, the 

28 total time between the start and stop events is calculated for each project, based on 

29 the logged data. In other embodiments, the total time elapsed between the start and 

30 stop events is individually cumulated for each project-assigned desktop. In the latter 

31 embodiments, it is sufficient to store only one number for each desktop, indicating the 

32 time already elapsed for the different desktops. For example, if a user generates a 
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1 start and a stop event in a certain desktop, the time between these events is deter- 

2 mined and added to the previously stored cumulated time, which is then replaced by 

3 the sum representing the new cumulated time for this desktop. In both embodiments, 

4 the logged data representing the start and stop events or the cumulated times are 

5 persistently stored, for example in a database or file in the user's computer, or in a 

6 centralized database or file accessible via a network to which the user's computer is 

7 connected. 

8 In some of the embodiments, project-time related statistics data (e.g. the times 

9 spent on the different projects) are prepared and/or output at predetermined time 

10 intervals, for example daily, weekly, monthly, yearly, eta In other embodiments, proj- 

11 ect-time-related statistics data are prepared and/or output on user demand, for ex- 

12 ample by the user clicking on a project-time-statistics icon. In both cases, a project- 

13 time-statistics tool is invoked which aggregates the project-time data (e.g. calculates 

14 the project times spent from logged event data) and exports the desired statistics 

15 data into files of a desired format or into a database. Formats of files can be spread- 

16 sheets, raw structured text (with defined delimiters, such as tabs), HTML reports (by 

17 using predefined project-statistics templates), etc. The project-time-statistics tool 

18 also enables the user to define whether to continue with the existing project-time data 

19 (a report to be prepared is then an intermediate report) or to reset the project-time 

20 data (in order to start with a new project or a project's new step). A reset may be indi- 

21 vidually made for the different projects* 

22 In some of the embodiments, the user is able to configure the multi-desktop- 

23 and-project-time-tracking system by means of a configuration tool. For example, the 

24 configuration tool enables the user to define: the association of one or more desktops 

25 to a particular project; (normally project-related) desktop names; the time-tracking 

26 type (e.g. logging individual start and stop events or storing cumulated project-time 

27 data); the way in which start and stop events are generated; the way and format in 

28 which project-time statistics data are to be generated and presented (e.g. regularly 

29 and/or on a user request), as well as additional attributes, for example priority data, 

30 etc. 

31 As already mentioned above, in some of the embodiments the user is able to 

32 d fine, as individual desktop settings, the link icons individually for the virtual desk- 
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1 tops* Hence, upon switching from one of the desktops to another, different link icons 

2 are displayable. In some of these embodiments, in addition to the link icons, the user 

3 is also able to determine further desktop settings individually for the virtual desktops. 

4 These further desktop settings are, for example, resources (such as assigned hard- 

5 ware devices), positions of the link icons within the desktop, short-cuts, background 

6 pictures etc. Hence, upon switching from one of the desktops to another, different 

7 further desktop settings become active. 

8 In these embodiments, the user can therefore not only assign the different 

9 desktops to different projects to track the time spent on them, but also individually 

10 adapt the desktops to the different projects- For example, typically each project le- 

1 1 quires different applications, data files, web sites, resources, short-cuts, etc. By virtue 

12 of the ability to define link icons (and, optionally, further desktop settings), the user 

13 may specifically define for each desktop those link icons (and further desktop set- 

14 tings) which pertain to the project to which the respective desktop is assigned, 

15 thereby creating a project-time-tracking system based on project-specific desktops 

16 (however, as mentioned above, it should be noted that in some embodiments the 

17 functionality of individually definable link icons (and further desktop settings) is real- 

18 ized without project-time-tracking functionality, in other embodiments the two funo- 

19 tionalities are combined). 

20 In embodiments with individually definable link icons, upon a switch from one 

21 virtual desktop to another, the desktop settings of the old desktop (i.e. the desktop 

22 active up to the switch) are stored, the desktop settings of the newly selected desktop 

23 (also called "the new desktop") are retrieved, and the retrieved desktop settings are 

24 used as the desktop settings for the new desktop. 

25 The way this is implemented in practice may depend on the operating system 

26 used in the computer (it is noted that the term "operating system" is often used in a 

27 strict sense meaning that portion of the software that runs in kernel mode (see, for 

28 example, A. Tanenbaum: Modem Operating Systems, 2* edition, 2001, pp. 1-3)). 

29 Herein, the term "operating system" is used in a broader sense including software 

30 that is typically sold together as "operating system"; it hence includes software, such 

31 as a graphical user interface, which may run not in kernel mode, but rather in user 

32 mode. 
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1 In current Microsoft Windows (MS) operating systems (e.g. Windows 95/98 or 

2 NT 2000) the information about desktop elements is stored in two different locations: 

3 data representing what desktop elements are to be placed on the desktop Is stored 

4 in a desktop directory, and data representing where each element is to be placed is 

5 stored in the registry. Current MS Windows operating systems provide only one vir- 

6 tual desktop. The embodiments which are extensions to those single-desktop oper- 

7 ating systems therefore extend the single-desktop manager's functionality to a multi- 

8 desktop functionality which enables the user to switch between several desktops 

9 having individual desktop settings. Upon receipt of a switch event, the desktop set- 

10 tings of the old desktop are exported from the desktop directory and the registry and 

11 are stored at another place, e.g. an individual-desktop-settings database, and the 

12 desktop settings of the new desktop are imported therefrom into the desktop direc- 

13 tory and the registry. Application windows of tasks associated with the old desktop 

14 are minimized, and may even be removed from the task bar, and application win- 

15 dows of tasks associated with the new desktop are resized (or maximized) and dis- 

16 played in the task bar. Thereby, tasks associated with non-active desktops keep on 

17 running in the background, and their application windows are only minimized and 

18 resized. Based on the switch events, and, optionally, on other start and stop events, 

19 the multi-desktop-and-project-time-tracking extension also implements the project- 

20 time-tracking functionality, as described above. 

21 Other embodiments are extensions to operating systems having desktop man- 

22 agers able to switch between several desktops "out of the box", such as Unix or Unix 

23 derivate operating systems, including Linux (called -Unix/Linux" hereinafter). Such 

24 desktop managers, for example, are KDE, GNOME, and CDE. In these available 

25 systems, all desktops of a user use the same desktop settings. Each of these sys- 

26 terns stores the desktop settings in different locations and formats. In embodiments 

27 of the extension with desktops which can be individualized, the desktop settings are 

28 retrieved, stored and set, either directly, or by an API (Application Program Interface). 

29 Ttie extension subscribes at the desktop manager to receive desktop-switch events. 

30 The available Unix/Linux systems have different mechanisms for handling events: 

31 KDE's mechanism is based on Trolltech's GUI class library; GNOME provides its own 

32 class library; and CDE is mostly based on X11 events. Irrespective of these differ- 
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1 ences, in some of the embodiments, the extension: (i) subscribes to receive desktop 

2 switch events; (ii) upon receipt of a switch event, stores the desktop settings of the 

3 old desktop; (iii) retrieves the stored desktop settings of the new desktop; (iv) as- 

4 signs project-time information to the respective desktops, e.g. a cessation of work to 

5 the old desktop and a commencement of work to the new desktop. 

6 The embodiments of the computer program product with program code for 

7 performing the described methods include any machine-readable medium that is 

8 capable of storing or encoding the program code. The term "machine-readable me- 

9 dium* shall accordingly be taken to include, but not to be limited to, solid state memo- 

10 ries, optical and magnetic storage media, and carrier wave signals. The program 

1 1 code may be machine code or another code which can be converted into machine 

12 code, such as source code in a multi-purpose programming language, e.g. C or C++. 

13 The embodiments of a computer include commercially available general-purpose 

14 computers programmed with the program code. 

16 Returning now to Fig. 1, it illustrates a GUI with an exemplary virtual desktop 1. 

16 The desktop 1 has a desktop background 2, for example a blank screen, a regular 

17 pattern or a background picture, also called "wallpaper". Different desktop elements 

18 are placed on the background 2, for example link icons 3, a pop-up menu 4, and a 

19 control panel 5 with control icons. Active applications are represented by task icons 6 

20 in a task bar 7. A mouse cursor 9 is a further desktop element; its movement on the 

21 desktop 1 represents movements of a pointing device, such as a mouse or a track- 

22 ball. There may also be invisible (i.e. purely logical) desktop elements, such as short- 

23 cuts (certain combinations of keys) which may, for example, start a task or trigger 

24 another activity. The user is able to define and alter the desktop elements, their funo 

25 tions, locations, shapes, and sizes. Furthermore, an application window 8 may be 

26 open for some or all of the active applications; it represents an output/input interface 

27 to the application it is associated with. Although task icons 6 and application win- 

28 dows 8 are automatically created and deleted when a task is started or stopped, at 

29 least the size, shape and location of the application windows in the desktop 1 can be 

30 modified by the user. The desktop elements can be d fined and configured individu- 

31 ally for different virtual desktops as will be illustrated in connection with Fig. 2. Since 

32 diff rent tasks are associated with the d sktops in which th y are started, and only 
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these tasks are displayed in the associated desktop, the presence of task icons 6 

2 and application wi ndows 8 is also desktop-individual. 

3 The GUI of Fig. 1 also shows multi-desktop-and-project-time control elements. 

4 e.g. grouped in a control bar 10. Strictly speaking, the control bar 10 does not form a 

5 part of the desktop 1, since it serves to control the different virtual desktops and is 

6 therefore a kind of "meta-control" element, largely or completely invariant under 

7 desktop switches. It has two groups of controls, e.g. in the form of graphical buttons. 

8 The first group includes desktop-switch controls 1 1 , e.g. in the form of graphical but- 

9 tons. By clicking with the cursor 9 on one of the desktop-switch buttons 1 1 , the user 

10 can initiate a switch to the dicked desktop. The currently displayed (i.e. active) 

11 desktop is indicated in the control bar 10, e.g. by highlighting the desktop-switch 

12 button 11 which represents the currently displayed desktop (which is, for example, 

13 desktop D2 in Fig. 1). The second group includes project-time-tracking controls. A 

14 start button 12 and a stop button 1 3 enable the user to indicate a commencement or 

1 5 cessation of work. By clicking on a dead man's button 1 4 the user can show that he or 

16 she is still present (in other embodiments, the dead man's button is realized by a 

17 short-cut which can be actuated more easily than a graphical button). A project-time- 

18 statistics button 15 enables the user to initiate an evaluation and output of project- 

1 9 time-related statistics. A project-time-contlguration button 1 6 gives the user access to 

20 a project-time-configuration page (see Fig. 7 below). The control bar 10 also pro- 

21 vides an indication of whether the time currently elapsing is counted as work time or 

22 as pause time, e.g. by highlighting the start or stop button, or by a separate indicator 

23 element (in the example of Fig. 1 , the start button 12 is highlighted indicating that the 

24 current time is counted as work time). 

25 In other embodiments, the project-time-related control elements 12-16, or some 

26 of them, are not meta-control elements, but are configurable in a desktop-individual 

27 way. For example, in some of the desktops, start and stop buttons may be useful, 

28 whereas In other desktops no such buttons are displayed. Likewise, in some desk- 

29 tops, no user-feedback is required, so that the dead man's button is omitted; other 

30 desktops requiring user-feedback provide such a button. 

31 Fig. 2 illustrates a switch from one d sktop 1 ("D2" in the example of Fig. 2) to 

32 another desktop V ("D3" in Fig. 2). Desktop 1 displays certain desktop-individual link 



200209986 15 

1 icons 3 ("A". "B", and "C w in Fig. 2). Two tasks, Tx" and Ty", are active in the desk- 

2 top 1 and are indicated by corresponding task icons 6. For one of these tasks, Ty, an 

3 application window 8 is displayed in the desktop 1. The different desktop elements, 

4 such as the link icons 3, as well as the size and position of application windows 8 are 

5 individually defined and configured for each desktop. 

6 Data indicative of the time spent by the user in the currently active desktop 1 is 

7 stored in a manner associated with the current desktop 1 . This is symbolized in Fig. 2 

8 by desktop-time-related data which is associated with D2, and are stored in a desk- 

9 top-time database 17. Several alternatives of how desktop-time or project-time data 

10 may be recorded are described below in Figs. 3-6. 

11 When the user initiates a switch-over to another desktop 1\ for example by 

12 clicking on a desktop-switch button 11 representing a currently inactive desktop (in 

13 Fig. 2: D3"), the desktop settings of the old desktop 1 (D2) are persistently stored in 

14 an individual-desktop-settings database 18, and the (previously stored) desktop set- 

15 tings of the new desktop 1' (D3) are retrieved therefrom and are used, instead of the 

16 old settings, to build up the new desktop 1'. This storage and retrieval of the desktop- 

17 individual settings is also illustrated in Fig- 2. Similarly, data representing the task 

18 icons 6, the application windows 8 as well as application windows settings, such as 

19 the position, size and shape of the application windows, are also stored for each 

20 desktop, for example in a dedicated application-windows database. As can be seen 

21 in the example of Fig. 2, different link icons 3' fE" and "F") are displayed at different 

22 locations in the new desktop 1\ Similarly* different task icons 6 and application win- 

23 dows 8 are displayed in the new desktop T. 

24 Since now the new desktop r is active, data indicative of time spent are now 

25 recorded in a manner associated with the new desktop 1' in the desktop-time data- 

26 base 17. 

27 Fig. 3 is a flow diagram illustrating the desktop switching and project-time- 

28 tracking-process carried out in the computer. Fig. 3 shows an embodiment in which 

29 the project-time recording is started and stopped by the user switching from one to 

30 another desktop. It is assumed that, wh n the process shown in Fig. 3 begins, a cer- 

31 tain desktop is already active (for example, when the user starts or logs in to the 

32 computer, the desktop which was active before the last shut-down or, in a multi-user 
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1 system, before the last log-out of this user, will be activated again). At 20, it is ascer- 

2 tained whether a switch event to another desktop has occurred. For example, a 

3 switch event may be the user clicking on a desktop-switch button or inputting a desk- 

4 top-switch short-cut referring to a currently inactive desktop. If the answer is negative, 

5 the observation performed at 20 is continued, but no further activity is performed. 

6 However, if a switch event is observed, a group of project-time-tracking activities (21 

7 and 22) and a group of desktop-switch activities (23, 24 and 25) are performed. At 

8 21 , a "stop" event is logged, for example together with a user identification (ID) iden- 

9 tifying the currently logged-in user, a workstation ID identifying the currently used 

10 workstation, an ID of the old desktop used up to now, and data representing the cur- 

1 1 rent date and time. At 22, a "start event" is logged, for example, with the user ID, the 

12 workstation ID, the ID of the new desktop, date and time. In other embodiments, only 

13 a "switch event" is logged instead of the stop and start events in 21 and 22. The 

14 switch event may indicate the IDs of both the old and the new desktop (In principle, it 

15 is even sufficient to log only one of the IDs, far example only the ID of the new desk- 

16 top. since the previously logged switch event contains the ID of the old desktop). At 

17 23, the desktop settings of the old desktop are stored. At 24, previously stored 

18 desktop settings of the new desktop are retrieved- At 26. the new desktop is built up 

19 in the graphical user interface, based on the retrieved desktop settings. Then, the 

20 process continues with the switch-event observation at 20. A shut-down or log-out 

21 causes a "stop event" to be logged, and a start of the computer or log-on causes a 

22 "start event" to be logged. 

23 An alternative embodiment with regard to how the project-time is recorded is 

24 also displayed in Fig. 3, by dashed lines. This embodiment is not based on logging 

25 events from which the project-time may later be calculated, but uses cumulative time 

26 counting. For example, a timer is provided which is reset and started when a desktop 

27 is activated; hence, its contents represents the time elapsed since the desktop has 

28 been activated. Cumulated active-desktop times are persistently stored for all desk- 

29 tops in a desktop-time database. At 21', the contents of the timer, i.e. the time the old 

30 desktop has been active since its last activation, is added to the cumulated desktop- 

31 time of the old desktop, and the previously stored cumulated value is overwritten by 

32 this sum. At 22". th recording of the active time of the new desktop is started by re- 
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1 setting the timer. When the computer is started or the user logs in, only the activity 22 

2 Is carried out. There are several variants of the cumulated desktop-time recording. 

3 For example, rather than resetting the timer upon activation of a desktop, the timer 

4 may start with the desktop time already cumulated for this desktop. If a switch away 

5 from this desktop occurs, the contents of the timer already represents the cumulated 

6 time; hence, its contents may simply be stored for this desktop (by overwriting the 

7 previously stored desktop time for this desktop). In a still further alternative embodi- 

8 ment, the cumulated desktop time stored in the desktop-time database is perma- 

9 nentiy incremented for the currently active desktop, e.g. every minute. Upon switching 
10 from one desktop to another no further storing activity is required since the stored 

1 cumulated desktop times are already up to date. 

12 Fig. 4 is a flow diagram similar to Fig. 3 of another embodiment in which the 

13 project-time recording can be started and stopped independently of a desktop 

14 switch. In the embodiment of Fig. 4, it is not only ascertained at 20, whether a switch 

1 5 event has occurred, but also, at 26 and 27, whether a start event or a stop event has 

16 occurred. A start event, for example, may be the user showing activity after a stop, or 

17 actuating the start button. A stop event may be a failure to exhibit any user activity for 

18 a specified inactivity time, an actuation of the stop button by the user, or a failure to 

19 press the "dead-man's button" for more than the accepted dead time. If a start event 

20 is observed, it is logged at 22, or the recording of the active time of the new desktop 

21 is started at 22', as explained above in connection with Fig. 3. If a stop event is ob- 

22 served, it is logged at 21 , or the recorded active time of the old desktop is added to 

23 the cumulated time of the old desktop at 21'. as explained above in connection with 

24 Fig. 3. If a switch event is observed, the group of desktop switch activities 23, 24 and 

25 25, as explained above in connection with Fig. 3, is performed. The independence of 

26 start and stop events from desktop switch events according to Fig. 4 enables times in 

27 which the user is inactive, or does not want to have the time recorded for other rea- 

28 sons, to be excluded from the project-time recording. Of course, in embodiments rep- 

29 resented by Fig. 4, switch events may also form start and/or stop events. For exam- 

30 pie, even if a user is able to expressly start and stop project-time recording, it may be 

31 assumed that switching to a n w desktop implies that the project-time recording 

32 ought to be immediately started for the new desktop; the switch event is then also 
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1 considered as a start event for time recording in the new desktop (and, optionally, as 

2 a stop event for time recording in the old desktop, if the project-time recording was 

3 active). By contrast, in other embodiments, the user may be required to expressly 

4 start the project-time recording after a desktop switch; in such embodiments, a switch 

5 to a new desktop may automatically stop the time-recording (if it was active in the old 

6 desktop); a switch event is then also considered as a stop event for the time record- 

7 ing in the old desktop. 

8 Figs. 5 and 6 illustrate the two different ways of project-time tracking (which 

9 have already been mentioned above in Figs. 3 and 4) in more detail. 

10 According to the embodiment illustrated in Fig. 5. upon appearance of an event, 

1 1 such as a switch event, a start or stop event, or a log-in or log-out event, a record is 

12 written in the desktop-time database, which is here, for example, in the form of an 

13 event-log file 29. Each record may indicate the event type, the ID of the active desk- 

14 top, and the date and time of the event. In the embodiment shown in Fig. 5, five differ- 

15 ent event types are logged: log-in, log-out. switch to, start, and stop. Although a 

16 "switch to" event implies a stop of the time recording in the desktop active up to the 

17 switch and a start of the time recording in the desktop active after the switch, these 

18 "implied events" are not expressly logged in Fig. 5. Similarly, although a log-In hv 

19 plies a start of the desktop-time recording (e.g. in a default desktop, or the desktop 

20 which was used by the present user the last time) and a log-out implies a stop of the 

21 time recording, the corresponding start and stop events are not expressly logged. 

22 Rather, in Fig. 8, only start and stop events which appear within a desktop session 

23 are recorded (e.g. starts and stops triggered by the user actuating the start or stop 

24 button). In other embodiments, such "implied" start and stop events are also logged, 

25 to introduce some redundancy. 

26 In regular intervals, or when the user actively requests a report on the time spent 

27 by him or her on the different projects (e.g. by clicking on the statistics button 15 in 

28 Fig. 1), a report is prepared by the multi-desktop-and-project-time-tracking system. 

29 Using the events in the log file 29. the times during which the different desktops were 

30 activ , excluding those time intervals when the time recording during a desktop ses- 

31 sion was stopped, is individually calculated for th different desktops. In the example 

32 of Fig. 1, for desktop "1" a desktop time of 0:25 h b tween the "log-in" and the 
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1 "switch/to/desktop 3" is obtained, for desktop "2" a desktop time of 2:23 h between 

2 the "switch/to/desktop 2" and the "stop 2" and between the "start 2" and the "log-out" 

3 is obtained, and for desktop "3" a desktop time of 0:46 h between the "switch-to 

4 desktop 3" and the "switch/to/desktop 2" event is obtained. In embodiments with a 

5 1:1 relationship between desktops and projects the desktop times obtained in this 

6 way already represent the project times of the projects to which the desktops are as- 

7 signed (in the simplest case, the desktop numbers correspond to project numbers, so 

8 that the report could simply state the desktop number/project number and the corre- 

9 sponding desktop/project time; in other embodiments, different project identifiers 

10 may be mapped to the desktops and included in the report). In the more general case 

11 of a N:1 relationship a corresponding mapping 30 between desktops and projects is 

12 provided. In the example of Fig. 5, two desktops (desktops "1" and "3") are mapped 

13 to one and the same project (project "1"). Based on the mapping 30, the desktop 

14 times (calculated as described above for 1:1 relationships) assigned to the same 

15 project are added. Correspondingly, the exemplary project-time report 31 in Fig. 5 

16 states that the time spent on project "1" is 1:1 1 h. on project "2" 2:23 h, and on project 

17 "3" 0:00 h. 

18 In other embodiments^ the N:1 mapping is already applied when the events are 

19 written to the log file; the data records then include a project ID. The project times are 

20 then obtained by adding the time intervals between switch events and start/stop 

21 events individually for each project ID taking into account the mapping from desktop 

22 to projects, analogously to what has been explained above for desktop times in the 

23 case of a 1 :1 relationship. 

24 According to the other embodiment illustrated in Fig. 6, the project-time tracking 

25 is based on cumulating project or desktop times. In the embodiment of Fig. 6, the 

26 time elapsing in an active desktop from switching to this desktop, or starting the time 

27 recording in this desktop, to switching to another desktop, or stopping the time re- 

28 cording; is recorded by a timer 32. For example, exemplary Fig. 6 illustrates the point 

29 of time immediately before the log-out in Fig. 5; the desktop time recorded in 32 

30 therefore refers to desktop 2. and the recorded time is 1:45 h. Cumulated desktop 
times for each desktop are stored in the desktop-times database 17, here, for exam- 



31 



32 pie, in the form of a table. In Fig. 6, an exemplary snapshot representing the table's 
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1 state immediately before the log-out of Fig. 5 Is shown at 33*. It includes the cumu- 

2 lated desktop times of all desktops up to "start 2" of Fig. 5; the current desktop ses- 

3 sion in desktop "2", lasting from "start 2" to the log-out is not yet included in the cu- 

4 mulated-desktop-times table. At the end of the current desktop session, i.e. upon the 

5 log-out in Fig. 5, the desktop time recorded in 32 is added to the data record of the 

6 cumulated desktop-times table referring to the current desktop, i.e. to desktop "2". 

7 The resulting snapshot of the table Is shown at 33" in Fig. 6. In the case of an 1 :1 re- 

8 lationship, the cumulated times contained in the cumulated-desktop-times table 4- 

9 ready represent the project times, and can immediately be output in a project-time 

10 report. In the case of an N:1 relationship, the cumulated desktop times are mapped to 

1 1 project times, by mappings 30, as described in connection with Fig. 5. Finally, a proj- 

12 ect-time report 31 is prepared, as in Fig. 5. 

13 In other embodiments of the cumulated-project-time recording similar to Fig. 6, 

14 the timer 32 is not reset upon a switch or start event but the timer 32 is started with 

15 already cumulated desktop time for the current desktop read in from the table in the 

16 state 33\ and is increased as time elapses during the current desktop session. When 

17 the session is terminated, the time recorded then by the timer 32 is written back to 

18 the cumulated-desktop-times table, which then results in a snapshot as 33". In still 

19 another embodiment, instead of using a timer, the table's record pertaining to the 

20 presently active desktop is constantly updated, e.g. Incremented every minute. In all 

21 three cases, at the end of the session (i.e. when the log-out happens), the snapshot 

22 33" is obtained. 

23 Fig. 7 shows an exemplary interface 35 of a configurator of the multi-desktop- 

24 and-project-time-tracking system which may be activated by the user, e.g. by clicking 

25 on configuration button 16 in Fig. 1. The configurator enables the user to define the 

26 settings of the project-time-recording system described so far. Upon starting the con- 

27 figurator, the graphical configuration interface 35 is displayed in an application win- 

28 dow. The user can specify the total number of virtual desktops in an edit box 36 and 

29 the total number of projects in an edit box 39. For each desktop, the user can specify 

30 a desktop label and the ID of the project to which the desktop is assigned, in edit 

31 boxes 37 and 38. A text description of each project can be entered at 40. Several 

32 controls for the definition of start and stop events are provided, for example a control 
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1 41 for activating the start/stop buttons, a control 42 by which the user can define that 

2 time recording is to be started with user activity, a control 43 by which the user can 

3 define that the time tracking is stopped in the case of inactivity for a user-definable 

4 time period, and control 44 by which the dead-man's button functionality can be acti- 

5 vated and the accepted dead time be defined. Finally, by means of pull-down menus 

6 45, the user can choose a period after which project-time reports are automatically 

7 generated, the file type of the reports and the location where they are stored. 

8 Fig. 8 is a diagrammatic representation of layers of a computer including multi- 

9 desktop-and-project-time tracking software for an exemplary Unix/Linux system. The 

10 lowest layer is a hardware layer 51 including a CPU, memory, disks, a terminal, a 

1 1 dock, etc. The other layers are software layers; the lowest software layer is the kernel 

12 52 of the operating system. It is responsible for process management, memory man- 

13 agement, the file system, input/output, etc. and runs in kernel mode. On top of the ker- 

14 nel 52 is a layer 53 including utility programs of the operating system, including the 

15 GUI, the window management system, the virtual-desktop management which e> 

16 ables the user to switch between different desktops with individually definable link 

17 icons, the project-time tracking system, etc. On top of the utility programs layer 53 are 

18 user applications 54. The utility programs 53 and the user applications 54 run in user 

19 mode. In other operating systems, for example Windows operating systems, a num- 

20 ber of the utility programs also run in kernel mode, and hence belong to the kernel. In 

21 some of these embodiments, the virtual-desktop-and-project-time tracking system 

22 also belongs to the kernel, it may then be an integrated part of the Windows operating 

23 system. In other embodiments, however, the entire or a part of the multi-desktop-and- 

24 project-time tracking system runs in user mode, for example when it is an extension to 

25 current Windows operating systems. 

26 Fig. 9 is a high-level architecture diagram of a multi-desktop-and-project-time- 

27 tracking system 56. It includes a multi-desktop manager 57 with a pager 58. a proj- 

28 ect-time tracker 59, a project-time statistics evaluator 60, a configurator 61 as well as 

29 databases 18, 17 for storing individual-desktop settings data and project-time data. 

30 The multi-desktop manager 57 provides the desktop-switch functionality described 

31 above. The pager 58 displays the desktop-switch buttons 1 1 of Fig. 1 and. upon ac- 

32 tuation of one of them, causes the multi-desktop manager 57 to perform the e- 
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1 quested desktop switch. In order to provide the different desktops with individually- 

2 definable link Icons, and other desktop settings, the multi-desktop manager 57 stores 

3 the desktop settings of the old desktops in, and retrieves the ones of the new desktop 

4 from, the individual-desktop-settings database 18. The multi-desktop manager 57 is 

5 also responsible for providing the other controls of the multi-desktop-and-project- 

6 time-control bar 10 of Fig. 1 , for example the start and stop buttons 12, 13, the dead- 

7 man's button 14. the project-time statistics button 15 and the project-time configura- 

8 tion button 16 of Fig. 1. based on specifications by the configurator 61 (which, in turn, 

9 may be entered by the user by means of the configurator's interface shown in Fig. 7). 

10 If an event relevant for project-time tracking occurs (be it a switch event, or another 

11 event indicative of a start or stop of work, such as an actuation of the start and stop 

12 buttons, exhibiting user activity after a stop, or failure to exhibit such an activity for a 

1 3 specified time, not operating the dead-man's button, etc.), the multi-desktop manager 

14 57 notifies the project-time tracker 59 of the event. For example, the project-time 

15 tracker 59 may be subscribed at the multi-desktop manager 57 to receive such 

16 events; if an event occurs, the multi-desktop manager 57 then actively notifies the 

17 project-time tracker 59, In alternative embodiments, the project-time tracker 59 regu- 

18 lariy sends notification requests to the multi-desktop manager 57, and if an event has 

1 9 occurred since the last notification request, the multi-desktop manager 57 returns the 

20 requested event notification to the project-time tracker 59. 

21 The project-time tracker 59 provides the project-time-tracking functionality de- 

22 scribed above. On the basis of event notifications, and information received from the 

23 multi-desktop manager 57 (i.e. information identifying the currently active desktop 

24 and/or the desktop from which or to which a switch is carried out), the project-timer 

25 tracker stores event-representing data in the desktop-time database 17, or increases 

26 cumulated desktop-time counters in the desktop-time database 17. as described in 

27 connection with Figs. 5 and 6. 

28 The project-time statistics evaluator 60 prepares project-time reports 31 based 

29 on data in the project-time database 17. as described in connection with Figs. 5 and 

30 6. The reports are prepared on user request (the user may, for example, actuate the 

31 statistics button 1 5 (Fig. 1 )), or on a regular basis. 
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1 The configurator 61 provides the graphical configuration interface 35 (Fig. 7) to 

2 the user and configures the multi-desktop manager 57 with the pager 58, the project- 

3 time tracker 59 and the project-time statistics evaluator 60 in accordance with the 

4 settings of the project-time-recording system defined by the user via the configuration 

5 interface 35. 

6 Fig. 1 0 is an architecture diagram similar to Fig. 9 illustrating an embodiment in 

7 which the multi-desktop-and-project-time-tracWng system 56 is formed by an exten- 

8 sion 63 to a MS Windows operating system. In Fig. 10, only the relevant parts of the 

9 MS Windows operating system are reproduced, i.e. the usual single-desktop man- 

1 0 ager 64 including an API 65 and a Windows desktop directory 66, as well as a part of 

1 1 the Windows registry 67. 

12 The switching between two desktops is performed by minimizing all open appB- 

13 cation windows, storing representations of the desktop elements of the old desktop 

14 and removing the desktop elements from the GUI. retrieving desktop-elements repre- 

15 sentations of the new desktop and displaying the retrieved elements in the GUI, and 

1 6 eventually maximizing application windows of tasks associated with the new desktop. 

17 Thereby, tasks associated with non-active desktops keep on running in the back- 

1 8 ground, and their application windows are only minimized and resized. 

19 In MS Windows, data representing the desktop elements of the (single) desktop 

20 are stored in the desktop directory 66. Data representing the positions of the desktop 

21 elements are stored at 68 within the Windows registry 67 at 68. In order to provide 

22 the multi-desktop manager tonctionality described in connection with Fig. 9, a multi- 

23 desktop extension 5T with a pager 58 is provided. It is similar to the multi-desktop 

24 manager 57 and pager 58 of Fig. 9, but uses the functionality of the single-desktop 

25 manager 64 already provided by the MS Windows operating system. In order to per- 

26 form a desktop switch, it retrieves the data representing the desktop elements, and 

27 their positions, of the old desktop from the desktop directory 66 and the Windows 

28 registry 67, stores them in the individual-desktop-settings database 18. and then re- 

29 trieves the corresponding data for the new desktop from the individual desktop- 

30 settings database 1 8 and stores them in the desktop directory 66 and the registry 67 

31 at 68. Application windows associated with the old desktop are minimized (and may 

32 also be removed from the task bar), and application windows associated with th 
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1 new desktop are resized (and may now also be iconized in the task bar). As a corv 

2 sequence, the desktop elements, application windows and task icons of the old 

3 desktop disappear from the GUI and their functionality is inactivated, whereas the 

4 ones of the new desktop are displayed in the GUI, and their functionality is activated. 

5 This represents a virtual-desktop switch for the user. Some of the functions of the 

6 project-time-tracking extension 56 are based on functions provided by the MS Win- 

7 dows operating system. For example, the multi-desktop-and-project-time-control bar 

8 10 (Fig. 1 ) is implemented via the API 65, and the operating system notifies the multi- 

9 desktop extension 57' via the API 65 if a control of the control bar 10 is actuated. 

1 0 Concerning further features and functions, the mutti-desktop-and-project-time-tracking 

1 1 extension 63 is similar to the system 56 described in connection with Fig. 9, so that 

12 reference is made to the description of Fig. 9 above. 

13 Fig. 11 is an architecture diagram similar to Fig. 10 illustrating another em- 

14 bodiment in which the virtuaWesktop-and-project-time-tracking system 56 is mainly 

15 formed by an extension 69 to a Unix/Linux operating system. Current Unix/Linux- 

16 based GUIs, such as KDE, GNOME. CDE, already provide a multi-desktop function- 

17 ality. Consequently, the relevant part of the operating system reproduced in Fig. 11 is 

18 a multi-desktop manager 64". including a pager 58", an API 65", and a desktop- 

19 settings database 70. Although the Unix/Linux operating systems provide a multi- 

20 desktop functionality, the desktop settings stored at 70 are the same for all desktops 

21 of one and the same user. Hence, the different desktops differ only with regard to 

22 tasks and application windows, but display the same link icons and other desktop 

23 elements. (Since Unix/Linux are multi-user operating systems, another user may have 

24 different desktop settings. However, to display the different desktop, the other user 

25 has to log in to the computer. Herein, activation of a different desktop due to a log-in, 

26 log-out, or switch to another user, is not considered a "desktop switch 11 ). 

27 The project-time tracking extension 69 uses the multi-desktop functionality of the 

28 Unix/Linux operating systems. A desktop extension 57" enables individual desktop 

29 elements to be displayed upon a desktop switch, by storing the desktop settings of 

30 the old desktop stored at 70 in th individual-desktop-settings database 18, retriev- 

31 ing the d sktop settings of the new desktop from the database 1 8 and storing them at 

32 70, either directly or via the API 65". The desktop ext nsion 57" is subscribed at the 
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1 multi-desktop manager 64" to receive desktop-switch events as well as other events 

2 relevant to project-time tracking, such as start and stop events, e.g. triggered by an 

3 actuation of the start or stop button 12, 13 (Fig. 1). When such an event occurs, e.g. 

4 when the user switches to another desktop by means of the pager 58", the API 65" 

5 notifies the desktop extension 57" of the event. In some of the embodiments, the 

6 multi-desktop manager 64" also informs the desktop extension 57" which one of the 

7 desktops is currently active (in other embodiments this may be omitted since the 

8 switch event carries sufficient information). Concerning further features and functions, 

9 the project-time-tracking extension 56 is similar to the system described in conneo- 

10 tion with Figs. 9 and 10, so that reference is made to the description of Figs. 9 and 

11 10 above. 

12 The hardware 51 shown in Fig. 8 may include primary storage, such as a main 

13 memory, a static memory and/or a volatile memory. It may further include secondary 

14 storage, such as magnetic and/or optic disk storage devices. The software embody- 

15 ing the multi-desktop-and-project-time-tracking system 56 (Fig. 9) or the corre- 

16 sponding extensions 63 and 69 (Figs. 10 and 1 1), or any other of the methodologies 

17 described above, is a set of instructions residing, completely, or at least partially, 

18 within the first and/or second storages. The software may further be transmitted or 

1 9 received via a network interface of the computer in the form of earner wave signals. 

20 All publications and existing systems mentioned in this specification are herein 

21 incorporated by reference. 

22 Although certain methods and products constructed in accordance with the 

23 teachings of the invention have been described herein, the scope of coverage of this 

24 patent is not limited thereto. On the contrary, this patent covers all embodiments of 

25 the teachings of the invention fairly falling within the scope of the appended claims 

26 either literally or under the doctrine of equivalents. 



